src/components/DashboardLayout.tsx (1)

366-404: Optimistic updates without rollback on failure.

The handleMarkRead, handleDeleteNotification, and handleClearAll handlers perform optimistic UI updates but silently swallow API errors without rolling back the local state. While this is acceptable for non-critical actions like mark-read, users may be confused if deleted notifications reappear on page refresh.

Consider adding a toast notification on failure, or rolling back the optimistic update:

💡 Example with rollback for delete

   const handleDeleteNotification = useCallback(
     async (notifId: string) => {
+      const prev = notifications;
       setNotifications(prev => prev.filter(n => n.id !== notifId));
       setNotifTotal(prev => Math.max(0, prev - 1));
       try {
         await fetch(`${apiBase}/api/notifications/${notifId}`, {
           method: 'DELETE',
           headers: { Authorization: `Bearer ${token}` },
         });
-      } catch {}
+      } catch {
+        // Rollback on failure
+        setNotifications(prev);
+        setNotifTotal(t => t + 1);
+      }
     },
-    [apiBase, token]
+    [apiBase, token, notifications]
   );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/DashboardLayout.tsx` around lines 366 - 404, The optimistic
updates in handleMarkRead, handleDeleteNotification, and handleClearAll
immediately mutate local state but swallow fetch errors, so failures aren’t
surfaced and state isn’t rolled back; update each handler (handleMarkRead,
handleDeleteNotification, handleClearAll) to capture the previous state before
mutating, attempt the API call, and on catch restore the prior state and surface
an error (e.g., call a toast/error handler or set an error state) so the UI
reflects the true server state; ensure you only clear the saved previous state
after a successful response to avoid memory leaks.

src/components/TeamManagement.tsx (2)

411-461: Invite acceptance from URL lacks duplicate-submission protection.

If a user refreshes the page while the invite is still in the URL (?invite=<token>), the acceptance flow will be triggered again. While the backend likely rejects already-accepted tokens, the UX could be confusing (showing "Accepting invitation…" followed by an error).

Consider clearing the URL parameter after initiating the request, or checking inviteResult state before re-triggering:

💡 Suggested improvement

   useEffect(() => {
     if (!inviteToken) return;
+    // Clear the invite param from URL to prevent re-triggering on refresh
+    const url = new URL(window.location.href);
+    url.searchParams.delete('invite');
+    window.history.replaceState({}, '', url.toString());
+
     const capturedToken = inviteToken;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/TeamManagement.tsx` around lines 411 - 461, The invite
auto-accept effect can re-trigger on page refresh; fix by removing the invite
query param immediately after capturing it and also short-circuiting if an
invite result already exists: inside the useEffect that reads inviteToken (the
effect containing capturedToken, setInviteAccepting, setInviteResult,
loadDashboard, updateUser), after const capturedToken = inviteToken call remove
the invite param via const url = new URL(window.location.href);
url.searchParams.delete('invite'); window.history.replaceState({}, '',
url.toString()); and at the top of the effect return early if inviteResult is
set (e.g. if (inviteResult) return;) to prevent duplicate submissions.

---

1067-1089: Per-member usage fetch lacks loading state feedback and race condition handling.

When clicking a member tab, the fetch is initiated inline within the onClick. If the user clicks multiple member tabs rapidly, multiple concurrent fetches can occur, and memberUsageLoading may be set to false by an earlier request completing after a later one starts, causing incorrect loading state display.

Consider debouncing or tracking which member is currently loading:

💡 Suggested improvement

+  const [loadingMemberUsageId, setLoadingMemberUsageId] = useState<string | null>(null);

   // In the onClick handler:
   onClick={async () => {
     setUsageTab(m.userId);
     if (memberUsageCache[m.userId]) return;
-    setMemberUsageLoading(true);
+    setLoadingMemberUsageId(m.userId);
     try {
       // ... fetch
     } finally {
-      setMemberUsageLoading(false);
+      setLoadingMemberUsageId(null);
     }
   }}

   // In the loading check:
-  {memberUsageLoading ? (
+  {loadingMemberUsageId === usageTab ? (

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/TeamManagement.tsx` around lines 1067 - 1089, The onClick
fetch starts inline and uses a single boolean memberUsageLoading which races
when clicks happen rapidly; change to track loading per-member (e.g., introduce
currentMemberLoadingId or a memberLoading map) and only clear loading or write
results if the response matches that tracked id. Specifically, in the onClick
handler around setUsageTab and setMemberUsageLoading, set a
currentMemberLoadingId (or set memberLoading[m.userId]=true), include that id
with the fetch (or use an AbortController), and when the fetch resolves/rejects
only call setMemberUsageCache and setMemberUsageLoading(false) if the stored
currentMemberLoadingId equals m.userId (or update the map for that user),
ensuring stale responses don't flip the global loading state; reference
setUsageTab, memberUsageCache, setMemberUsageCache, setMemberUsageLoading, and
m.userId to locate and update the code.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes